AFO 813 – Stack requests
813.1 Introduction
See the general help on stack requests for more information on the general principles.
This AFO contains most of the regular maintenance functions for stack requests.
Overview of the workflow, From Stacks to Library
1. On printing of the request slips, the bookstacks staff will attempt to find the item(s) requested.
2. The essential workflow in the movement of the item from the stacks to the recipient library is that the item is checked out when moving out from a location, and checked in when coming into a location. At all points the check out and check in routines will check the status of the item being wanded, to see whether that item has a current request in process.
3. When the item is ready to be shipped, it is checked out. At this point, the request file is checked to confirm that this item has an active request for it. If not, the user is warned, and the item can be put aside for return to the stacks.
4. If batching of books is used, the system behaves differently according to the situation; when checking items out of the stacks, entry into the checkout process retrieves and displays the next available batch number; the first item then checked out defines the route that the batch will take; this is prompted and must be acknowledged by the user. Subsequent items are then checked that they conform to this route. The batch is closed by leaving the checkout process, at which point the user is asked whether they wish to add a note to the batch
5. At this point, the status on the item record is changed, indicating that the item is in transit from the stacks to the recipient library. The item is shipped out, and its status changes accordingly.
6. On arriving at the next location, the item processed accordingly. If this location is an intermediate station, the individual item or batch can be processed in and out, or directly through the station. Again, the implied route is displayed, and must be acknowledged by the user. At the Reading Room, the items, if batched, are unpacked. At this point, the item status again changes (it is now awaiting collection).
7. The item is now held behind the counter for the period defined in the Processing Pattern for the current Stack Location code.
8. If during this time, another reader requests the item from the counter, the system checks the whether the system configuration allows other readers to “jump the queue”.
9. If the item is not requested at the library either by the current requestor, or by any other reader, or the item is returned after being consulted or borrowed by another reader than the current requestor, then the item is checked in for return to the stacks. If the item is checked in from a current stack request, then the system will prompt the user to ask whether the item is to be retained for further consultation; if so, the stack request just serviced remains current, i.e. the reader is still first in the queue; if so, the PIECE record has a status flagged to indicate this.
10. If there are other current stack requests for this item, at this location, the system notifies the user of this, and the item is held back by the library, the new stack request (first in line) becoming the current one.
11. ‘Local' requests for the item take priority over current requests for the item at other libraries, the system checks line 11 in the processing pattern. If this is set to 0 or blank, then the item is put in to transit ‘normally' to the new library. If set to 1, the item is returned to the stacks. On being checked in there, the new stack request is then activated.
12. If the item is transited directly, or via the stacks, to satisfy another stack request, then, on the item arriving at the new location, we start again at 1 above.
13. If at this point, however, there are no other current stack requests, then the item is cleared for return to the stacks.
After selecting this AFO, a submenu will be displayed:
The various menu options are described in the next sections.
813.2 Alerts
This option is reserved for future use.
813.3 Stack requests
This section describes how requests are presented and retrieved in the system.
After selecting this option, an overview screen will be displayed:
This presents a breakdown of the requests according to the current status of the request. A request will appear in all the service points pertinent to the request.
Selection of a specific line will lead to a listing of the individual requests comprising the total shown, from which the individual request can be selected to get to the detailed display. However, for completed and rejected requests, the display will be limited to the most recent 500 requests, since to report on all could take a very long time.
Options on the screen
: This option leads to the standard bibliographic search screen. You can use this to create a new request, similar to the functionality of AFO 421.
: Select a status line and then this option to view the requests with this status. See section 813.3.1 for details.
: This option allows specific searches to be made against the requests database. See section 813.3.2 for details.
: This option allows specific searches to be made against the requests database. See section 813.3.3 for details.
813.3.1 Select request status
: Select a status line and then this option to view the requests with this status. An overview screen will be displayed:
Options on the screen
: This option leads to the standard bibliographic search screen. You can use this to create a new request, similar to the functionality of AFO 421.
: Select a line and then this option to display the details of a request. See section 813.3.1.1.
: Select this option to print a listing of requests in the section. After choosing this option a selection form will be displayed:
This lists the mailmerge documents made available via AFO 815 – Request summary print setup. After selecting a document from the dropdown list and clicking , the standard screen for generating mailmerge type output will be displayed.
813.3.1.1 Tabs on the form
Tab general
The General tab shows some overall details of the request. The information that is system generated or results from the transactions / history of the request is displayed in protected form.
Fields on the screen
Title: The title of the requested work (protected field).
Request status: The current status of the request. This is a multiline display since there may be several conditions worth reporting (protected field).
Alerts: Reserved for future use.
Request number: A system generated number.
Request date: The date and time that the request was entered.
Required by: The date for post-dated requests.
Reservation priority: This options allows you to assign a priority to a request which has been placed as a reservation (i.e. where there is a queue of requests). The lower the number the higher the priority. This field appears only if the parameter “Use reservation priorities” in AFO815 - System wide options is ON.
This is NOT related to reservations priority as described above for regular reservations.
Expiry date and Expiry time: A system calculated date/time. These are calculated from the expiry date/time/rule settings of the stack request code. If a ‘reservation' request is created, the Reservation expiry period or Reservation expiry date field is used to calculate the Expiry date and Expiry time. Otherwise, the regular three fields are used.
Confirm request: For non-catalogued items, when entered either by staff or from the WebOPAC, the request is left in a “review” state, for staff checking.
Staff notes: For notes to staff.
Placed: The location, date / time and user ID details of request placement (protected field).
Request code: Determined from the borrower category (protected field).
Source of request: How the request was entered – this will be set to the value “WebOPAC” if entered that way, otherwise staff may select from the dropdown list
This may be used for reporting purposes.
Internal system record id: The internal record number (protected field).
Note
Depending on the status of the request, other fields may be protected as well.
Tab bibliographic
This tab shows the bibliographic details for the selected item and bib record. There are two variations on this display :
Catalogued items
In this case, the selected item may not be changed, once input but the current status is displayed here. Although, in such cases we expect the material to be monographic, the “volume” information possibly entered against the request initially is displayed and may always be amended.
Non catalogued items
This is much the same display – but for non-catalogued items. In this case, the pseudo item details are displayed and may be amended.
If the location details are amended, the system will cross-reference the route previously selected to ensure that it is consistent with the location details entered.
Note that the item category, assigned a default value when the request was entered initially may be changed.
Tab client
This tab holds the reader / borrower information, and some input fields relating to the reader aspects of the system.
In particular it displays the name and details of the reader. Additional changeable fields are:
Delivery location: The delivery location. This may be changed under very limited circumstances only.
Table id: A table if defined for the delivery location.
Use in library only: Notes that the item may only be used in the library.
Contact method: The preferred mechanism for any correspondence to the client. In addition to printing and/or emailing the relevant notices to the reader, it is also possible to indicate here that the availability of the request should be sent as a Text message.
Reader notes: A free text note field that will display to the reader in the WebOpac.
Charge to client: The charge for placing a stack request.
Once placed then the amount is NOT changeable.
Under very limited circumstances, the borrower initially entered may be changed, using the [Borrower] command.
Expected delivery date: An estimated date for delivery is calculated, based on the settings for the service point. This may change during the processing of the request.
Original expected delivery: The original calculation, based on the settings for the service point.
Blocked: If a borrower fails to collect requested items, then the system will create a “block” against their record, based on parameters in the Stack Request Code. This block will ONLY apply to the ability to place stack requests.
Additional tab Request source
This tab only appears when the request is for a non-catalogued item. This portion of the form is hidden for catalogued records. It represents the bibliographic data entered when the request was initially entered.
Data may be corrected at any time.
813.3.1.2 Buttons on the form
: When you click this button, an input form appears:
It allows the user to carry out specific actions on the request. These may sometimes be carried out by other methods. For example, the Action/Event button may be used to checkout the item to the reader, but this may also be executed from the regular AFO411 Checkout also.
The Action/Event pops up an input form offering a variety of options. The options offered are sensitive to the current context of the request – an obvious example might be that the option to checkout the item is not offered if it has already been recorded as checked out!
Possible actions are :
· Print or reprint the request
· Checkin the item/request
· Send a message to the reader
· Cancel the request
· Clear the block for the current request
: When you click this button, an overview screen appears:
This displays a log of the key events in the lifecycle of the request. You can click on a line to get more details:
: When you click this button, an overview screen appears:
This gives an overview of the transfer of the item from stack location to the delivery point. This is for information purposes only.
813.3.2 Bibliographic search
: This option allows specific searches to be made against the requests database.
The Bibliographic search brings up the standard search input form.
However, when the search is carried out, the system will automatically limit the search to those titles for which a request exists (or existed at any time!)
813.3.3 Request search
: This option allows specific searches to be made against the requests database.
A special search form appears:
Fields on the screen
Search term: is the expression to be used for the search.
Search type: offers a dropdown list of various types. See below for the differences.
The following fields allow the search to be further qualified.
Request status: offers this dropdown list of possible requests statuses.
Dates: This set of four fields allows the user to define a date range – based on a specific type of date from the request.
Limit search to current transactions: This will limit the search to requests which are neither completed nor rejected – for example, if searching by borrower then only their current requests are displayed. This may, of course, conflict with the selected status.
813.3.3.1 Search types
By borrower
The search term for a borrower may be either the borrower barcode number or a name. If this is selected then this behaves as a regular borrower search, and either a unique match or a list of matching borrowers is returned.
When a specific borrower is selected, the system will effectively return the borrower record, from which the list of requests for that borrower may be selected.
On the assumption that any one borrower has a relatively small number of requests at any one time, the additional filters are NOT relevant at this point.
To all intents and purposes, this search is the same as going to AFO431, finding a borrower and listing their ILL requests. The key point is that it saves effort in swapping backwards and forwards between AFOs.
By request id and service point
Searching by service point allows for the searching by the name of a defined service point OR by their code. Searching by name implies a right truncation (thus "Main" would find "Main service point") and if this is ambiguous (e.g. Main reading room, Main stack location) then a screen will offer a selection.
Searching by request id also implies right truncation – thus "ASR1" would find "ASR1", "ASR11" etc. You can search by either internal or external ID of the request.
In either case, if the result generates multiple matches, then a summary listing, as shown in, will be displayed from which the user may selected a specific request.
By item barcode
This allows you to find the requests for a specific item barcode. There are no wildcards or similar options - the results are for the item entered only.